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Foreword 



This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage three Protocol Description of the Completion of Communications to Busy 
Subscriber (CCBS) service and the Completion of Communication on no Reply (CCNR) service, based on stage one 
and two of the ISDN supplementary services. It provides the protocol details in the IP Multimedia (IM) Core Network 
(CN) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). 

The Completion of Communications to Busy Subscriber CCBS service enables user A, encountering a busy 
destination B, to have the communication completed without having to make a new communication attempt when the 
destination B becomes not busy. 

The Completion of Communications on No Reply CCNR supplementary service enables user A, encountering a 
destination B which does not answer the communication (No Reply), to have the communication completed without 
having to make a new communication attempt when the destination becomes not busy after having initiated an activity. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the CCBS and CCNR supplementary services. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] and the following 
terms and definitions apply. 

busy: See ITU-T Recommendation 1.221 [8], subclause 2.1.5. 

call information retention: A procedure of network A to store the call information of a specific call so that it can be 
used for that call. 

caller: The user who originated the call and to whom the CCBS service is provided. 
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callee: The user which is identified as destination B. 

CC: Completion of Communication 

CC busy: Any one of the following conditions will cause a CCBS busy condition: 

maximum number of calls reached at user A (see ITU-T Recommendation 1.221 [8], subclause 2.1.3, item 2)); 

no resources (bandwidth) available at user A; 

CC recall pending on user A. 

CCBS/CCNR call: A call generated by the network connecting the caller to the callee, resulting from the callers' 
acceptance of a CCBS/CCNR recall. 

CCBS/CCNR recall: An indication informing the caller that the network is ready to initiate a CCBS/CCNR call to the 
callee and that the network is awaiting a response to this indication. 

CCBS/CCNR request: An instance of an activation of the CCBS/CCNR service which is held in a queue pending the 
correct conditions for the CCBS/CCNR service to be completed. 

Suspended CCBS/CCNR request: A CCBS/CCNR request which cannot be served even if the callee is in the 
appropriate state because the caller is busy. 

CCBS/CCNR request retention: If an attempt to establish a CCBS/CCNR call fails because the destination is busy 
again, then the network provider option "CC request retention" defines whether the CCBS supplementary service is 
continued or not, i.e. if the "CC request retention" is supported, the original CCBS/CCNR request retains its position in 
the queue B, and monitoring of user B shall continue. Otherwise the CCBS/CCNR request is revocated. 

CC service duration tinier: A maximum time the CC service will remain activated for the caller within the network. 

destination B: The entity addressed in the original call. 

long-term denial: The network cannot accept user A's request to activate the CC service and a later attempt to activate 
the CC service for the same destination B will also be rejected. 

queue A: A buffer at the originating side for the control of CCBS/CCNR requests associated with the caller. 

queue B: A buffer at the terminating side for the control of CCBS/CCNR requests associated with destination B. 

retain option: The retain option, if supported in both the originating and destination network, will maintain the 
CCBS/CCNR request in the destination B queue, if a CCBS/CCNR call has failed due to destination busy condition. 

short-term denial: The network temporarily cannot accept user A's request to activate the CC service. A later attempt 
to activate the CC service for the same destination B may succeed. 

UE-A: The caller" s UE. 

UE-B: The callee"s UE. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AOC Advice Of Charge 

AS Application Server 

CB Communication Barring 

CC Completion of Communications 

CCBS Completion of Communication to Busy Subscriber 

CCNR Completion of Communications on No Reply 

CD Communication Deflection 

CDIV Call Diversion 

CFB Communication Forwarding Busy 

CFNL Communication Forwarding on No Logged-in 

CFU Communication Forwarding Unconditional 
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CN 

CNR 

CONF 

CS 

CW 

ECT 

HOLD 

IFC 

IM 

IMS 

IP 

ISDN 

MCID 

MIME 

OIP 

OIR 

PLMN 

PSTN 

SIP 

TIP 

TIR 

UE 



Core Network 

Completion of communication on No Reply 

CONFerence calling 

Circuit Switched 

Communication Waiting 

Explicit Communication Transfer 

Communication HOLD 

Initial Filter Criteria 

IP Multimedia 

IP Multimedia Subsystem 

Internet Protocol 

Integrated Service Data Network 

Malicious Communication IDentification 

Multipurpose Internet Mail Extensions 

Originating Identification Presentation 

Originating Identification Restriction 

Public Land Mobile Network 

Public Switch Telephone Network 

Session Initiation Protocol 

Terminating Identification Presentation 

Terminating Identification Restriction 

User Equipment 



Completion of Communications to Busy Subscriber 
(CCBS) / Completion of Communication on No Reply 
(CCNR) 



4.1 



Introduction 



The CCBS and CCNR services enables a user, encountering a destination that is busy or does not answer, to have the 
communication completed at a later point in time without the user having to manually initiate a new communication 
attempt. 

4.2 Description 
4.2.1 General description 

The CCBS service enables user A, encountering a busy destination B, to have the communication completed without 
the user having to manually initiate a new communication attempt when the destination B becomes not busy. 

When user A requests the CCBS supplementary service, the network will monitor for destination B becoming free 
again. 

When destination B becomes free again, the network will wait a short time in order to allow the resources to be re-used 
for originating a communication. If the resources are not re-used by destination B within this time, the network will 
automatically recall user A. 

When user A accepts the CCBS recall, the network will automatically generate a CCBS call to destination B. 

The CCNR supplementary service enables user A, encountering a destination B which does not answer the 
communication (No Reply), to have the communication completed without the user having to manually initiate a new 
communication attempt when the destination becomes not busy after having initiated and completed a new 
communication. 

When user A encounters a destination B which does not answer the communication (No Reply), user A can request the 
CCNR supplementary service. 
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When user A requests the CCNR supplementary service, the network will monitor for destination B becoming not busy 
after having initiated and completed a new communication. 

When destination B becomes not busy after having initiated and completed a new communication, the network will wait 
a short time (as defined by the destination B idle guard timer) in order to allow the resources to be reused for originating 
a communication. If the resources are not reused by destination B within this time, the network will automatically recall 
user A. 

When user A accepts the CCNR recall, then the network will automatically generate a CCNR call to destination B. 

The CCBS / CCNR service control is done by the application servers. It is possible to modify the queue by the users 
(add entry, delete entries, delete whole queue) by usage of appropriate procedures. 

On the originating side the originating AS A manages the queue of user A and on terminating side the terminating AS B 
manages the queue of outstanding communications towards UE B. 

The originating AS keeps track of the CCBS/CCNR requests started by each user for a given period of time, and rejects 
a new request in case the provisioned limit has been overcome. 

The terminating AS keeps track of the CCBS /CCNR requests directed to each user for a given period of time, and 
rejects a new request in case the provisioned Umit has been overcome. 

After successful CCBS/CCNR Call setup the respective entry is deleted in both queues. Also a proper management of 
the queue in the suspend/resume scenario upon reception of the corresponding message takes place. 

4.3 Operational requirements 
4.3.1 Provision/withdrawal 

The CCBS/CCNR service is provided to the served user after prior arrangement with the service provider, or as a 
service provider option. Withdrawal of these services is made on the served user's request or for service provider 
reasons. 

4.4 Coding requirements 

No specific requirements needed. 

4.5 Signalling requirements 

4.5.1 Activation/deactivation 

The call completion services are individually activated at provisioning or at the subscriber's request. 
The call completion services are individually deactivated at withdrawal or at the subscriber's request. 

4.5.2 Registration/erasure 

The CCBS/CCNR service requires no registration. Erasure is not applicable. 

4.5.3 Interrogation 

For the interrogation of the call-completion services the Ut interface using XCAP as enabling protocol as described in 
3GPP TS 24.623 [4] or SIP based user configuration as described in 3GPP TS 24.238 [7] in combination with 
announcement procedures according to 3GPP TS 24.628 [3] could be used. 
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4.5.4 Invocation and operation 

4.5.4.1 Actions at the originating UE 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [2] shall apply. 

When the UE receives a SIP final response to the SIP INVITE request and the SIP response contains 

a) a Date header field; and 

b) a MIME body of the message/external-body MIME type as specified in IETF RFC 4483 [12] with: 

1. "access-type" MIME type parameter containing "URL"; 

2. "URL" MIME type parameter containing an HTTP URI identifying an element <cc-entry> stored in the 
XML document of the "users" tree of the communication completion request records XCAP application 
usage and the element <cc-entry> is identified by attribute selector using the "id" attribute; and 

3. "expiration" MIME type parameter; 

then the UE should use this information to inform the user that: 

a) if the date and time in the "expiration" MIME type parameter is later than the date and time of the Date header 
field, then the communication attempt has led to a communication completion invocation; and 

b) if the date and time in the "expiration" MIME type parameter is equal to or earlier than the date and time of the 
Date header field, then the communication attempt has led to a communication completion revocation. 

For invoking and revoking of the call completion services, announcement procedures according to 3GPP TS 24.628 [3] 
and inband-interaction procedures should be used. 

Editor's note: The usage of inband interaction procedures needs further studies and specification. For invoking and 
revoking of the call-completion services also out-of-band stimulus procedures according to ETSI TR 183 
057 [4] could be used. 

4.5.4.2 Actions at the originating AS 

4.5.4.2.0 General 

The originating AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] or operate as a 
routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] for the incoming INVITE request and all future 
requests and responses in the same dialog. 

4.5.4.2.1 CC Invocation 
4.5.4.2.1.1 Normal procedures 
4.5.4.2.1 .1.1 Detecting if CC is possible 

When in case of CCBS a 486 (Busy Here) response has been received from the terminating network, and the following 
set of conditions apply: 

the 486 (Busy Here) response contains a Call-Info header field with a "purpose" header field parameter set to 
"call-completion"; and 

the user A CCBS queue limit has not been exceeded; and 

CCBS has not been activated for an identical communication (network option), determined by the stored basic 
communication information defined in subclause 4.5.4.2.LL2; and 

there are no service interactions that preclude CCBS; 
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then the service retention procedure as specified in subclause 4.5.4.2.1.1.2 is executed. 

When in case of CCNR a 180 (Ringing) response has been received from the terminating network, and the following set 
of conditions apply: 

the 180 (Ringing) response contains a Call-Info header with a purpose parameter set to 'call-completion'; and 

the user A CCNR queue limit has not been exceeded; and 

CCNR has not been invoked for an identical communication (network option), determined by the stored basic 
communication information defined in subclause 4.5.4.2.1.1.2; and 

there are no service interactions that preclude CCNR, 

then the originating AS shall remove the Call-Info header from the 180 (Ringing) response, forward it to UE-A and start 
the CC no-reply timer CCNR-T5. When this timer expires then the service retention procedure as specified in 

subclause 4.5.4.2.1.1.2 is executed. 

4.5.4.2.1 .1 .2 Starting of the service retention procedure 

The originating AS shall start the retention timer CC-Tl. The originating AS shall retain the following information from 
the original communication, if available: 

1) SDP offer, and 

2) Request-URI, and 

3) To header field, and 

4) From header field, and 

5) Privacy header field, and 

6) P-Asserted-ID header field. 

4.5.4.2.1 .1 .3 CC service invocation by user A 

For the invocation of the CC service, in case of CCBS immediately after receipt of a 486 (Busy Here) response with a 
CCBS possible indication or in case of CCNR after receipt of a 180 (Ringing) response with a CCNR possible 
indication upon expiry of the No-Reply timer CCNR-T5, the originating AS shall provide an announcement that CC is 
possible to user A, according to 3GPP TS 24.628 [3], followed by inband-interaction procedures for the activation 
confirmation. 

NOTE: User A can have a limited number of CC requests outstanding. This limit is a network provider option 
(with a maximum value of 5). 

If user A does not confirm the activation of CC, the AS shall restore the communication condition from before the 
announcement and proceed with basic communication procedures by forwarding the 486 (Busy here) response in case 
of CCBS or sending a 199 (Early Dialog Terminated) on the announcement dialog in case of CCNR. 

4.5.4.2.1 .1 .4 Stopping of the service retention procedure 

On receiving a CC invocation confirmation from user A before the expiry of the retention timer CC-Tl, the originating 
AS shall: 

a) stop the retention timer CC-Tl; and 

b) store the retained call information from the original basic communication. 

As a network option, in case of receipt of a CCNR invocation confirmation, the originating AS may terminate the 
original communication by sending a CANCEL request to UE-B, in accordance with the procedures described in 
3GPPTS 24.229 [2]. 

NOTE: The above procedure avoids a race condition between answering the call at the terminating side and 
subscribing to CCNR at the originating side. 
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4.5.4.2.1 .1 .5 Sending of the CC invocation request to the terminating AS 

The originating AS shall send a SUBSCRIBE request to the terminating AS according to RFC 3265 [6] and 
RFC 6910 [5]. The originating AS shall populate the SUBSCRIBE request as follows: 

a Request-URI set to the URI returned by the terminating AS in the Call-Info header field of the response 
including the CC possible indication 

in case of CCBS as received in the Call-Info header field in the 486 (Busy Here) response, including an "m" 
SIP URI parameter with a value set to "BS"; 

in case of CCNR as received in the Call-Info header in the 180 (Ringing) response, including an "m" SIP 
URI parameter with a value set to "NR"; 

a From header field set to the URI of UE-A from the original communication; 

a To header field set to the URI of UE-B from the original communication; 

a Contact header field set to the URI of the originating AS; 

a Call-Info header field with the URI of UE-A from the P-Asserted-Identity, a "purpose" header field parameter 
set to "call-completion", and an m-parameter set to "BS" in case of CCBS or "NR" in case of CCNR; 

a P-Asserted-Identity header field as received from the original INVITE request; and 

NOTE 1 : If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted- 
Identity header field that contains an E.164 number is preferable. 

an Expires header field set to at least the initial value of the service duration timer CC-T3. 

The originating AS shall start the CC request timer CC-T2. 

NOTE 2: The To header field is used to identify a particular CC target. 

4.5.4.2.1 .1 .6 Procedures after CC invocation confirmation from the terminating AS 

If the originating AS receives a NOTIFY request as an answer to an outstanding CC request which was described in 
subclause 4.5.4.2.1.1.5 with the cc-state parameter set to 'queued', the originating AS shall: 

a) stop the CC request timer CC-T2; 

b) start the CC service duration timer CC-T3; 

c) store the information whether the cc-service-retention parameter has been received or not; and 

d) confirm to the caller that the invocation was successful, using announcement procedures according to 
3GPPTS 24.628 [3]. 

In case of CCBS the originating AS shall forward the 486 (Busy Here) response to UE-A. 

In case of CCNR, if the original communication with the UE-B has already been cancelled by the originating AS, the 
originating AS shall send a 480 (Temporarily unavailable) response to UE-A. 

The originating AS shall include in the SIP 486 (Busy Here) response or the SIP 480 (Temporarily unavailable) 
response: 

a) a Date header field containing the current date and time; and 

NOTE: To function correctly the Date header field cannot be removed from SIP response to SIP INVITE request 
by an IBCF between originating P-CSCF and originating S-CSCF 

b) an message/external-body MIME type as specified in IETF RFC 4483 [12] with: 

1. "access-type" MIME type parameter containing "URL"; and 

2. "URL" MIME type parameter containing an HTTP URI identifying an element <cc-entry> 
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i) representing the new communication completion request; 

ii) stored in the XML document of the "users" tree of the communication completion request records XCAP 
application usage; and 

iii) identified by attribute selector using the "id" attribute; 

3. "expiration" MIME type parameter containing the date and time of the communication completion request 
expiration. 

4.5.4.2.1.2 Exceptional procedures 

If the originating AS receives a 480 (Temporarily Unavailable) response (short term denial) or a 403 (Forbidden) 
response (long term denial), in accordance with the procedures of subclause 4.5.4.3.2.2, to an outstanding CC request 
which was described in subclause 4.5.2.2.1.1.5, then the originating AS shall: 

a) stop the CC request timer CC-T2; and 

b) confirm to the caller that the invocation was not successful, using announcement procedures according to 
3GPPTS 24.628 [3]. 

In case of CCBS the originating AS shall forward the 486 (Busy Here) response to UE-A. 

4.5.4.2.2 CC Revocation 

4.5.4.2.2.1 Normal procedures 

4.5.4.2.2.1 .1 Generating a revocation request 

For revoking the CC service, the originating AS shall send a SUBSCRIBE request to the terminating AS according to 
RFC 3265 [6] and RFC 6910 [5] in the SUBSCRIBE dialog. The originating AS shall populate the SUBSCRIBE 
request following normal procedures as specified in 3GPP TS 24.229 [2] with the following additions: 

a Call-Info header field with the URI of UE-A from the P-Asserted-Identity, a "purpose" header field parameter 
set to "call-completion", and an m-parameter set to "BS" in case of CCBS or "NR" in case of CCNR; 

a P-Asserted-Identity header field as received from the original INVITE request; 

NOTE: If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted- 
Identity header field that contains an E.164 number is preferable. 

and 

an Expires header field set to zero. 

4.5.4.2.2.1 .2 Revocation requested by the user 

If the originating AS receives a revocation request by the user, the originating AS shall 

construct a SUBSCRIBE request according to subclause 4.5.4.2.2.1.1; and 

send the SUBSCRIBE request to the terminating AS; and 

inform user A of the result of the revocation by using announcement procedures and inband-interaction 
procedures according to 3GPP TS 24.628 [3]. 

The originating AS shall include in the SIP final response to the revocation request: 

a) a Date header field containing the current date and time; and 

NOTE: To function correctly the Date header field cannot be removed from SIP response to SIP INVITE request 
by an IBCF between originating P-CSCF and originating S-CSCF 

b) an message/external-body MIME type as specified in IETF RFC 4483 [12] with: 
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1. "access-type" MIME type parameter containing "URL"; and 

2. "URL" MIME type parameter containing an HTTP URI identifying an element <cc-entry> 

i) representing the communication completion request being revoked; 

ii) stored in the XML document of the "users" tree of the communication completion request records XCAP 
application usage; and 

iii) identified by attribute selector using the "id" attribute; 

3. "expiration" MIME type parameter containing the date and time of the communication completion request 
revocation. 

4.5.4.2.2.1 .3 Revocation caused by timer expiry 

If the service-duration timer CC-T3 expires, the originating AS shall: 

construct a SUBSCRIBE request according to subclause 4.5.4.2.2.L1; and 
- send the SUBSCRIBE request to the terminating AS. 

4.5.4.2.2.2 Exceptional procedures 

The originating AS shall be prepared to receive a NOTIFY request caused by a service-duration timer expiry at the 
terminating AS, according to the procedures of subclause 4.5.4.3.3.2, with: 

the Subscription-State header field set to "terminated"; and 

the "reason" Subscription-State header field parameter set to "noresource". 

In this case the originating AS shall stop the CC service-duration timer CC-T3, if this timer is still running. 

4.5.4.2.3 CC Operation 

4.5.4.2.3.1 Normal procedures 

On receipt of a CC recall notification as described in subclause 4.5.4.3.4. 1 .2, and if user A is neither busy nor CC busy, 

the originating AS shall initiate the CC recall to user A by sending a REFER request to UE-A according to 

3GPP TS 24.229 [2], and shall start the recall timer CC-T4. The originating AS shall populate the REFER request as 

follows: 

a Request-URI set to the URI of UE-A from the original communication, including an "m" SIP URI parameter 
with a value set to "BS" in case of CCBS or "NR" in case of CCNR; and 

a Refer-to header set to the URI of UE-B. 

If there are multiple outstanding CC requests at the originating AS, then the correct target for the CC recall is identified 
using standard SIP dialog identification procedures. 

In the case UE-A does not support the REFER method extension, the special REFER request handling procedures 
according to 3GPP TS 24.628 [3] should be used. As a network option, e.g. in the case the originating AS has 
knowledge that UE-A does not support the REFER method extension, the originating AS may start the 3rd party call 
control procedures according to 3GPP TS 24.628 [3] without waiting for a 3xx - 6xx response. In this case, the 
originating AS shall send an INVITE request with a Request-URI set to the URI of UE-A from the original 
communication, including a "m" SIP URI parameter with a value set to "BS" in case of CCBS or "NR" in case of 
CCNR. The INVITE request shall include identity information about user B in the From header field as received in the 
To header field of the original request. Other identity information may be included if allowed by the Privacy settings in 
the response of the original communication. 

If user A accepts the recall before the CC recall timer expires (a NOTIFY request with a body containing SIP/2.0 100 
Trying or a 200 OK to the 3pcc INVITE request according to the special REFER request handling procedures according 
to 3GPP TS 24.628 [3] is received), the originating AS shall stop timer CC-T4 and initiate the CC call to destination B 
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by sending an INVITE request, in accordance with RFC 6910 [5]. The originating AS shall populate the INVITE 
request as follows. 

a Request-URI set to the URI of UE-B from the original communication, including an "m" SIP URI parameter 

- set to "BS" in case of CCBS; or 

- set to "NR" in case of CCNR; 

a From header field set to the URI of UE-A from the original communication; 

a To header field set to the URI of UE-B from the original communication. 

a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a 
"purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS and 
"NR" in case of CCNR; 

4.5.4.2.3.2 Exceptional procedures 

4.5.4.2.3.2.1 Non-acceptance of CC recall 

See subclause 4.5.4.2.2.1.3. 

4.5.4.2.3.2.2 User A is found busy or CC busy 

If the caller is found to be busy or CC busy, when a CC recall notification as described in subclause 4.5.4.3.4.1.2 has 
been received, then the originating AS shall suspend the CC request until the caller becomes not busy or not CC busy 
again. The originating AS shall send a PUBLISH request to the terminating AS according to RFC 6910 [5] in the 
existing SUBSCRIBE dialog. The originating AS shall populate the PUBLISH request following normal procedures as 
specified in 3GPP TS 24.229 [2] with the following additions: 

a Request-URI set to the contact address of the terminating AS returned by the terminating AS when the 
SUBSCRIBE dialog was created; 

a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a 
"purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS and 
"NR" in case of CCNR; 

a P-Asserted-Identity header field as received from the original INVITE request; 

NOTE 1 : If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted- 
Identity header field that contains an E. 164 number is preferable. 

an Expires header field set to the current value of the remaining duration of the subscription; and 

a body set to a PIDF informing about the basic state 'closed' for the caller's identity as presentity. 

When the caller is no longer busy or CC busy, then the originating AS shall resume the CC request. The originating AS 
shall send a PUBLISH request to the terminating AS according to RFC 6910 [5] in the existing SUBSCRIBE dialog. 
The originating AS shall populate the PUBLISH request following normal procedures as specified in 
3GPP TS 24.229 [2] with the following additions: 

a Request-URI set to the contact address of the terminating AS returned by the terminating AS when the 
SUBSCRIBE dialog was created; 

a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a 
"purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS and 
"NR" in case of CCNR; 

a P-Asserted-Identity header field as received from the original INVITE request; 

NOTE 2: If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted- 
Identity header field that contains an E. 164 number is preferable. 

an Expires header field set to the current value of the remaining duration of the subscription; and 
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a body set to a PIDF informing about the basic state 'open' for the caller" s identity as presentity. 

In case of the originating AS has sent several suspension requests to different terminating ASs and the caller becomes 
neither busy nor CC busy, the originating AS shall resume each suspended request. 

4.5.4.2.3.2.3 The caller makes another call to the same destination B 

If the caller initiates another communication to the same destination B and activates the same CC service (CCBS or 
CCNR) again, then: 

if the two communications are identical, then the following network provider options exist: 

1) the originating AS shall retain the original request with the current request being discarded and inform the 
caller that the request has not been accepted because a CC request had already been stored against the 
requested destination B; or 

2) the originating AS shall treat this as a new CC request; and 

if the two calls are not identical, then the originating AS shall treat this as a new CC request. In order to decide 
that the two calls are identical, the originating AS shall only compare the basic communication information, i.e. 
the SDP offer, the destination selection information, and calling user identity (if any). 

NOTE: It is a network provider option which information is used to identify identical communications. 

4.5.4.2.3.2.4 CC call failure 

If the CC call fails, the originating AS shall inform the caller as for the basic communication procedures. 

If CC is possible (a received 180 (Ringing) or 486 (Busy Here) response contains a Call-Info header field with a 
purpose parameter set to "call-completion"), two possibilities exist: 

if the retain option is supported across the networks (the originating AS has received a cc-service-retention 
parameter in the NOTIFY request described in subclause 4.5.4.3.2.1), the originating AS shall keep the 
transaction resources and shall not restart the service duration timer CC-T3. If the caller attempts to activate CC 
again, the originating AS shall treat this as described in subclause 4.5.4.2.3.2.3. 

if the retain option is not supported across the networks, the originating AS shall release the transaction 
resources. The originating AS shall deactivate the CC request and shall inform the caller accordingly. 

If CC is not possible (a received 180 (Ringing) or 486 (Busy Here) response does not contain a Call-Info header field 
with a purpose parameter set to 'call-completion'), the originating AS shall deactivate the CC request according to the 
procedures described in subclause 4.5.4.2.2 and shall inform the caller accordingly. 

4.5.4.3 Actions at the terminating AS 

4.5.4.3.0 General 

The terminating AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] or operate as a 
routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] for the incoming INVITE request and all future 
requests and responses in the same dialog. 

4.5.4.3.1 CC possible indication 
4.5.4.3.1.1 Normal operation 

When on an incoming communication the terminating AS supports the CCNR service, then the terminating AS shall 
insert a Call-Info header field with either the URI of the terminating AS or the URI received in the original INVITE 
request, a purpose-parameter set to 'call-completion', and an m-parameter set to 'NR' in the 180 (Ringing) response 
forwarded by the AS to indicate whether CCNR is possible or not, in accordance with RFC 6910 [5]. 

When on an incoming communication the callee is found to be busy and the terminating AS supports the CCBS service, 
then the terminating AS shall insert a Call-Info header field with either the URI of the terminating AS or the URI 
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received in the original INVITE request, a "purpose" header field parameter set to "call-completion", and an m- 
parameter set to "BS" in the 486 (Busy Here) response generated by the terminating AS (in case of 'network determined 
user busy') or forwarded by the terminating AS (in case of 'user determined user busy') to indicate whether CCBS is 
possible or not, in accordance with RFC 6910 [5]. 

If the terminating AS knows that the CC is not possible on destination B, the terminating AS shall not include a Call- 
Info header field with a "purpose" header field parameter set to "call-completion" in any response sent to the originating 
side. 

4.5.4.3.1.2 Exceptional procedures 

Not applicable 

4.5.4.3.2 CC Invocation 

4.5.4.3.2.1 Normal operation 

Several CC requests can be queued against one destination B in the destination B CC queue (queue B). The exact size 
of queue B (from 1 to 5 entries) is a destination network operator option. 

As a network option the destination network operator can reduce the sizes of the CC queues associated with individual 
users. The reduced size can be zero. The size of the CCBS queue can also be related to the size of the CCNR queue if 
existing. 

On receipt of a CC invocation request as described in subclause 4.5.4.2. 1. 1.5, the terminating AS shall: 

a) acknowledge the receipt of the SUBSCRIBE request with a 202 Accepted response. The terminating AS shall set 
the Expires header field in the 202 Accepted response to a value less or equal than the value of the Expires 
header field in the received SUBSCRIBE request, in accordance with RFC 3265 [6]. 

b) check if the Request-URI of the SUBSCRIBE request is available for the requested CC service; if there is no 
match, the terminating AS shall check if theURI in the To header field of the SUBSCRIBE request is available 
for the requested CC service; if it is available, the terminating AS shall store the information received in the CC 
invocation request in the destination B queue and send a NOTIFY request to the originating AS according to 
RFC 6910 [5]. The terminating AS shall populate the NOTIFY request as follows: 

a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request; 

a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

a Subscription-State header field set to "active"; 

the "expires" Subscription-State header field parameter set to the current value of the subscription duration, 

a body set to a cc-state parameter set to 'queued'; and 

if the retain option is supported at the terminating AS, a cc-service-retention parameter in the same body; 

c) start the service duration timer CC-T7; and 

d) monitor destination B 

in case of CCBS for becoming not busy; or 

in case of CCNR for becoming not busy after having initiated an activity. 
NOTE: Methods for monitoring the callee for becoming not busy are a network provider implementation option. 
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4.5.4.3.2.2 Exceptional procedures 

When the invocation of the requested CC service is rejected by the terminating AS, in accordance with RFC 6910 [5] 
the terminating AS shall send a 480 (Temporarily Unavailable) response (short term denial) or a 403 (Forbidden) 
response (long term denial), in the following cases: 

if there are already the maximum number of requests queued against destination B; 

if there is an interaction with other services which prevents the invocation of the requested CC service; 

if the URl in the To header field of the SUBSCRIBE request is not available for the requested CC service at 
destination B. 

If the callee is no longer busy when the CCBS invocation request arrives, the terminating AS shall apply the normal CC 
invocation procedures as described in subclause 4.5.4.3.2.1. 

If the callee has answered the communication when the CCNR invocation request arrives, the terminating AS shall 
apply the normal CC revocation procedures as described in subclause 4.5.4.3.3.1. 

NOTE: A general error, e. g. a syntax error, or a non-compliance to the call-completion event-package, is 
answered according to the procedures described in RFC 3265 [6]. 

4.5.4.3.3 CC Revocation 

4.5.4.3.3.1 Normal operation 

On receipt of a CC revocation request as described in subclause 4.5.4.2.2.1.1, the terminating AS shall delete the CC 
request from the destination B queue and send a NOTIFY request to the originating AS according to RFC 3265 [6] and 
RFC 6910 [5]. The terminating AS shall populate the NOTIFY request as follows: 

- a Request-URI set to the URI of the originating AS as received in the Contact header field of the SUBSCRIBE 
request; 

a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

a Subscription-State header field set to "terminated"; and 

the "reason" Subscription-State header field parameter set to 'timeout'. 

4.5.4.3.3.2 Exceptional procedures 

The terminating AS shall automatically revoke a particular request for the CC service if the CC service duration 
timer CC-T7 expires. If timer CC-T7 expires, the terminating AS shall send a NOTIFY request to the originating AS as 
described in subclause 4.5.4.3.3.1 with the "reason" Subscription-State header field parameter set to 'noresource'. 

4.5.4.3.4 CC Operation 
4.5.4.3.4.1 Normal operation 
4.5.4.3.4.1 .1 The callee becomes available 

When the callee becomes not busy, then the terminating AS shall check queue B: 

a) if there is an entry in the queue currently being processed, the terminating AS shall take no further action; 

b) otherwise, the terminating AS shall examine: 

the CCBS entries in the queue; and 

the CCNR entries in the queue, if the callee became not busy after having initiated an activity; 



£75/ 



3GPP TS 24.642 version 9.1 0.0 Release 9 21 ETSI TS 1 24 642 V9.1 0.0 (201 3-07) 

c) if an entry is suspended, the terminating AS shall take another entry; and 

d) if an entry is not suspended, the terminating AS shall select it for the CC recall. 

NOTE: The algorithm for the order addressing entries in the queue is outside the scope of this document. It needs 
not to be the order of creation of the queue entries. 

The terminating AS shall start the destination B idle guard timer CC-T8. When the destination B idle guard timer CC- 
T8 expires, the terminating AS shall process the selected CC request. 

4.5.4.3.4.1 .2 The CC recall is started 

When processing a CC request, provided that the callee is still available, the terminating AS shall start the CC recall 
procedure. 

The CC recall procedure is defined as follows: 

the terminating AS shall send a NOTIFY request to the originating AS according to RFC 6910 [5]. The 
terminating AS shall populate the NOTIFY request as follows: 

a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request 

a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

a Subscription-State header field set to "active"; 

the "expires" Subscription-State header field parameter set to the remaining duration of the subscription; 

a body set to a cc-state parameter set to 'ready'; and 

- the terminating AS shall start the CC recall timer CC-T9. 

4.5.4.3.4.1 .3 Incoming communication during the CC recall processing 

If the terminating AS receives an INVITE request while a CC recall is processed, the terminating AS shall check 
whether this new incoming communication includes a CC call indicator (an "m" SIP URI parameter is added to the 
Request-URI, or a Call-Info header field exists and includes an "m" header parameter). 

If the INVITE request includes a CC Call indicator, the terminating AS shall offer the incoming communication to the 
callee. 

If the INVITE request does not include a CC call indicator, the terminating AS shall reject the incoming communication 
by generating a 486 (Busy Here) response which includes a CC possible indication, according to the normal CC 
possible indication procedures described in subclause 4.5.4.3.1.1. 

4.5.4.3.4.1 .4 Procedures after the CC call was offered to the callee 

When the terminating AS has sent a 183 (Session Progress) response, a 180 (Ringing) response or a 200 (OK) response, 
it shall: 

- stop the timers CC-T7 and CC-T9; 

delete the CC request from the destination B queue 

send a CC revocation notification as described in subclause 4.5.4.3.3.2 to the originating AS; and 

if there are further CC requests to be processed, then check whether the callee is busy: 

if the callee is busy, the terminating AS shall take no further action; or 

if the callee is not busy, the terminating AS shall service the queue for destination B as described above. 
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4.5.4.3.4.1.5 Further procedures 

If the originating AS resumes a CC request according to the procedures describe in subclause 4.5.4.2.3.2.2 because user 
A has become free (i.e. not busy and not CC busy), then, if the callee is available and there is no entry in the CC queue 
which is currently being processed, the terminating AS shall service the destination B queue as described above. 

If the originating AS suspends a CC request according to the procedures describe in subclause 4.5.4.2.3.2.2, the 
terminating AS shall: 

stop timer CC-T9; and 

send a NOTIFY request to the originating AS, including a body with a cc-state parameter set to 'queued'; and 

attempt to process another CC request in the same queue. 

If the originating AS revokes a CC request according to the procedures described in subclause 4.5.4.2.2.1.1, the 
terminating AS shall stop timers CC-T7 and CC-T9 and attempt to process another CC request in the same queue. 

4.5.4.3.4.2 Exceptional procedures 

a) The callee is busy when destination B idle guard timer expires: 

If, upon expiry of the destination B idle guard timer CC-T8, the callee is busy (e.g. the callee has initiated an 
outgoing communication), then the terminating AS shall defer servicing of the destination B CC queue until the 
callee becomes not busy again. 

b) The terminating AS receives a "ready" notification while processing the destination B CC queue: 

See subclause 4.6.10. 

c) The callee is busy upon arrival of the CC call: 

If the callee is busy when a CC call arrives, then the procedures depend on whether the retain option is supported 
across the networks: 

if the retain option is not supported at the terminating AS, the terminating AS shall cancel the corresponding 
CC request; the terminating AS shall send a 486 (Busy Here) response with a Call-Info header field with a 
"purpose" header field parameter set to "call-completion" to the originating AS; if a new CCBS invocation 
request is received from the originating AS, normal procedures apply, according to subclause 4.5.4.3.2; 

if the retain option is supported at the terminating AS, the terminating AS shall retain the original CC request 
in the queue; in this case the terminating AS shall continue to monitor destination B, shall not restart the 
timer CC-T7, shall stop timer CC-T9 and shall send a 486 (Busy Here) response with a Call-Info header field 
with a "purpose" header field parameter set to "call-completion" to the originating AS. 

d) No CC call as result: 

If no CC call results from the CC recall mechanism, the recall timer CC-T9 expires. In this case the terminating 
AS shall send a NOTIFY request to the originating AS according to RFC 3265 [6] and RFC 6910 [5]. The 
terminating AS shall populate the NOTIFY request as follows: 

a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request; 

a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

a Subscription-State header field set to 'terminated'; and 

the "reason" Subscription-State header field parameter set to 'rejected'. 

4.5.4.4 Actions at the terminating UE 

Basic call procedures according to 3GPP TS 24.229 [2] shall apply. 
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4.5.5 SIP specific Event Notifications 

SIP specific Event Notifications shall be used in accordance with RFC 3265 [6] including as referenced in 
IETF RFC 6910 [5]. 

4.6 Interaction of Call-Completion with other services 

4.6.1 Communication waiting (CW) 

The CW AS shall not invoke the CW service on a CC recall. 

NOTE 1 : For a waiting communication, destination B is not considered as busy. 

If the communication waiting indication cannot be given at the destination B, user A will receive busy 
indication and can invoke the CCBS service to destination B. 

NOTE 2: Procedures for the case the CC call encounters busy again are described in subclause 4.5.4.3.4.2. 

4.6.2 Communication Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

NOTE: When receiving a CC recall indication, user A can invoke the communication hold service in order to 
make interface resources available for the establishment of the CC call. 

4.6.3 Terminating Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.4 Terminating Identification Restriction (TIR) 

The TIR AS shall enforce the privacy settings of the CC recall answer on the CC call and if necessary on the subsequent 
communication, if the CC recall was invoked via 3pcc procedures. 

4.6.5 Originating identification presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.6 Originating identification restriction (OIR) 

The OIR AS shall enforce the privacy settings of the originating call on the CC call. 

The OIR AS shall enforce the privacy settings of the originating call for SUBSCRIBE and NOTIFY requests when CC 
is invoked. 

4.6.7 Conference calling (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.8 Communication diversion services (CDIV) 
4.6.8.1 General 

The CDIV AS shall not divert a CC recall. The CDIV AS shall give a CC recall to user A at user A's original location. 
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4.6.8.2 Communication Forwarding Unconditional 

For CFU activated by B before A requests CC on B: 

If user B has activated CFU, and the forwarded communication results in a call-completion condition at user C, 
the CC AS shall inform user A that CC is possible at user C. If user A activates CC and subsequently activates 
CFU, the CDIV AS shall give the CC recall to user A at his original location. 
As a network option, in case of a diversion at user B, the CC AS shall not inform user A that CC is possible. 

For CFU activated by B after A requests CC on B: 

If user B activates CFU after user A has activated CC on user B, then the CC AS shall revoke the CC request by 
sending a NOTIFY request to the originating AS as described in subclause 4.5.4.3.3.1 with the "reason" 
Subscription-State header field parameter set to 'noresource'. The CC AS serving user A shall send a notification 
"CC cancelled" to the user A. 

As a network option, the CC AS shall suspend the CC request until user B deactivates CFU. If the service 
duration timer CC-T7 expires before user B deactivates CFU, the CC AS shall revoke the CC request as decribed 
in subclause 4.5.4.3.3.2. 

NOTE: How the "CC cancelled" notification is send to user A is FFS. 

4.6.8.3 Communication forwarding busy 

For CFB activated by B before A requests CC: 

If user B has activated CFB and is busy, and the forwarded communication results in a call-completion condition 

at user C, the CC AS shall inform user A that CC is possible at user C. 

As a network option, the CC AS shall inform user A that CCBS at user B is possible. 

For CFB activated by B after A requests CC on B: 

If user B activates CFB after user A has activated CC on user B, a CC call from user A which encounters a busy 
condition at user B shall be treated as follows: 

user B shall be considered as being busy and the CC AS shall apply the procedures of CCBS; or 

the CDIV AS shall forward the communication as a normal communication. 

4.6.8.4 Communication forwarding no reply 

For CFNR activated by B before A requests CC: 

If user B has activated CFNR and does not answer the communication, and the forwarded communication results 
in a call-completion condition at user C, the CC AS shall inform user A that CC is possible at user C. 
As a network option, the CC AS shall inform user A that CCNR at user B is possible. 

For CFNR activated by B after A requests CC on B: 

If user B activates CFNR after user A has activated CC on user B, a CC call from user A which encounters a no 
reply condition at user B shall be treated as follows: 

- the CC AS shall apply the procedures of CCNR; or 

the CDIV AS shall forward the communication as a normal communication. 

4.6.8.5 Communication forwarding not registered 

For CFNL activated by B before A requests CC on B: 

If user B has activated CFNL and is not logged in, and the forwarded communication results in a call-completion 
condition at user C, the CC AS shall inform user A that CC is possible at user C. 
As a network option, the CC AS shall inform user A that CCNR at user B is possible. 

For CFNL activated by B after A requests CC on B: 
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If user B activates CFNL after user A has activated CC on user B, then the CC AS shall cancel the CC request 
and shall send a notification "CCBS cancelled" to the user A. 

As a network option, the CC AS shall suspend the CC request until user B deactivates CFNL. If the service 
duration timer CC-T3 expires before user B deactivates CFNL, the CC AS shall cancel the CC request. 

NOTE: How the "CC cancelled" notification is send to user A is FFS. 

4.6.8.6 Communication deflection (CD) 

For the originating user A: 

If a communication to the called user B is deflected to user C by the CD service and results in a call-completion 
condition at user C, the CC AS shall inform user A that CC is possible at user C. The CDIV AS shall not deflect 
a CC recall. 

For the called user B: 

- The CDIV AS shall not deflect a CC call. 

4.6.9 Advice of charge (AOC) 

Charging information can be given for the original communication, and for the resulting CCBS communication. 

4.6.1 Completion of communications (CCBS/CCNR) 

A user can be both a "user A" and a "user B" simultaneously, i.e. that user can have activated the CC service and have 
CC requests outstanding whilst at the same time that user can be the destination of CC requests from other users. 

The CC AS shall handle CC requests activated by this user (the user's queue A) with priority over CC requests activated 
by other users on this user (the user"s queue B), see subclause 4. 5. 4.3.4. LL 

4.6.1 1 Malicious communication identification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.12 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.13 Message Waiting Indication (MWI) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.1 4 Explicit Communication Transfer (ECT) 

Editor"s note: For further studies. For ECT with REFER the transferee does not know to who he sends the INVITE, 
and if the SUBSCRIBE is sent on another dialog, the SUBSCRIBE may not reach the target AS. 

4.6.15 Flexible Alerting (FA) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.1 6 Customized Alerting Tones (CAT) 

No impact, i.e. neither service shall affect the operation of the other service. 
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4.7 



Void 



4.8 Parameter values (timers) 



4.8.1 

CC-Tl 

CC-T2 

CC-T3 

NOTE: 
CC-T4 
CCNR-T5 

4.8.2 

CC-T7 

NOTE: 
CC-T8 

CC-T9 



Timers referring to tine originating AS 



Retention timer. This timer specifies the amount of time that the network retains the communication 
information of the original communication which was not established successfully. After being informed 
that CC is possible the caller sends a CC invocation request before expiry of this timer. The minimum 
value of this timer is 15 seconds. 

CC request operation timer. Supervision of response to a CC activation request sent from the originating 
AS to the terminating AS. CC-T2 will expire if signalling is not possible, at signalling failures, or if the 
terminating AS cannot respond. The minimum value of this timer is 10 seconds. 

CC service duration timer. This timer specifies the maximum time the service will remain activated for 
user A. The maximum value of this timer is 180 minutes. 

The value of the CC service duration timer can differ in the network dependent on its usage for CCBS or 
CCNR. 

CC recall timer. This timer specifies the maximum time the originating AS will wait for a response from 
user A to a CC recall. The maximum value of this timer is 20 seconds. 

No-reply timer. This timer specifies the maximum time after which the originating AS will provide the 
announcement that CCNR is possible, and inband activation is possible. The maximum value of this timer 
is 20 seconds. 



Timers referring to tine terminating AS 



CC service duration timer CC-T7 expiry will only be meaningful if the expiry of CC-T3 has not been 
notified to the terminating AS. CC-T7 takes a longer duration than CC-T3, i.e. CC-T7 expires at 
abnormal situations only. The maximum value of this timer is 190 minutes. When CC-T7 expires, the CC 
request will be cancelled at the terminating AS as well as at the originating AS. 

The value of the CC service duration timer can differ in the network dependent on its usage for CCBS or 
CCNR. 

Destination B idle guard timer. This timer specifies the amount of time the terminating AS will delay 
after destination B has become free, before initiating a CC recall towards the originating AS. The 
maximum value of this timer is 10 seconds. 

Recall timer. CC-T9 should expire at emergency only, i.e. the recall should be cancelled by CC-T4 at the 
originating AS if recall is not responded to. Duration of CC-T9 = 20 seconds + some seconds for CC call 
set-up. The maximum value is 30 seconds. 



4.9 Communication completion configuration XCAP application 
usage 

4.9.1 General 

Communication completion configuration documents are sub-trees of the simservs XML document specified in 
3GPP TS 24.623 [4]. As such, communication completion configuration documents use the XCAP application usage in 
3GPPTS 24.623 [4]. 

Data semantics: The semantics of the communication completion XML configuration document is specified in 

subclause 4.9.2. 
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XML schema: Implementations in compliance with this specification shall implement the XML schema that minimally 
includes the XML Schema defined in subclause 4.9.3 and the simservs XML schema specified in subclause 6.3 of 
3GPPTS 24.623 [4]. 

4.9.2 Data semantics 

The active attribute of <communication-completion> element indicates whether the communication completion service 
is activated or not. 

The <communication-completion> element contains an optional <CCBS-CC-T3-timer> and optional <CCNR-CC-T3- 
timer> elements. 

The <CCBS-CC-T3-timer> is a read-only element and indicates the value, in minutes, of the CC-T3 of the CCBS. 

The <CCNR-CC-T3-timer> is a read-only element and indicates the value, in minutes, of the CC-T3 of the CCNR. 

4.9.3 XML schema 

<?xml version="l . 0" encoding="UTF-8"?> 

<xs : schema xmlns : ss="http : //uri . etsi .org/ngn/params/xml/simservs/xcap" 

xmlns :xs="http: //www.w3 . org/2 001/XMLSchema" 

targetNamespace="http : //uri .etsi .org/ngn/params/xml/simservs/xcap" 

elementFormDefault=" qualified" attributeFormDefault=" unqualified" 

> 

<xs : include schemaLocation="XCAP .xml"/> 

<xs : element name =" communication- completion" substitutionGroup="ss : absService" > 
<xs : annotation> 

<xs : documentation>communication completion</xs : documentation> 
</xs : annotation> 

<xs : complexType> 

<xs : complexContent> 

<xs : extension base="ss : simservType" > 
<xs : sequence> 

<xs:element name="CCBS-CC-T3-timer" type="xs ipositivelnteger" minOccurs=" 0"/> 
<xs:element name="CCNR-CC-T3-timer" type="xs ipositivelnteger" minOccurs=" 0"/> 
<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

</xs : schema> 



4.10 Communication completion request records 
4.10.1 General 

The communication completion request records XCAP application usage allows a UE to interrogate the communication 
completion AS to find out a list of the currently pending communication completion requests originated by a public user 
identity registered at the UE. 

The communication completion AS shall support acting as XCAP server as specified in IETF RFC 4825 [10] providing 
the communication completion request records XCAP application usage as specified in subclause 4.10.2 and shall 
support acting as notifier of the changes in the communication completion request records XML document using 
RFC 5875 [9]. 

The UE may support acting as XCAP client as specified in IETF RFC 4825 [10] accessing the communication 
completion request records XCAP application usage as specified in subclause 4.10.2 and may support acting as 
subscriber for the changes in the communication completion request records XML document using RFC 5875 [9]. 
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4.1 0.2 Communication completion request records XCAP application usage 

4.10.2.1 Application Unique ID (AUID) 

The AUID of the communication completion request records XCAP application usage is "org.3gpp.ccrr" 

4.10.2.2 XML schema 

The communication completion request records XML documents are composed according to the XML schema defined 
in this subclause. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns :xs="http: //www.w3 . org/2 1/XMLSchema" 

xmlns : ccrr= "urn : 3gpp : ns : ccrr : 1 . " 

targetNamespace="urn: 3gpp :ns : ccrr: 1.0" 

elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs : element name ="cc- records" type="ccrr :Tcomm-completion-req-records"/> 

<xs :complexType name="Tcomm-complet ion- req- records" > 
<xs : sequence> 

<xs:element ref ="ccrr : cc-entry" minOccurs="0" maxOccurs="unbounded"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence > 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : element name=" cc-entry" type="ccrr :Tcomm-completion-entry"/> 

<xs :complexType name="Tcomm- completion- entry" > 
<xs : sequence> 

<xs:element name="orig-URI" type="xs : anyURI"/> 

<xs:element name="called-URI" type="xs : anyURI"/> 

<xs:element name="term-URI" type="xs : anyURI" minOccurs=" 0"/> 

<xs:element name="expiration" type="xs :dateTime"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="id" type="xs : string" use="required"/> 
<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

</xs : schema> 

4.1 0.2.3 Default document namespace 

The default namespace of the communication completion request records XCAP application usage is 
"urn:3gpp:ns:ccrr: 1 .0" 

4.10.2.4 MIME type 

The MIME type of the communication completion request records XML document is specified in annex C. 

4.10.2.5 Validation constraints 

No additional constraints beyond those defined by IETF RFC 4825 [10] are defined. 

4.10.2.6 Data semantics 

The communication completion request records XML document contains a root element <cc-records> containing a list 
of <cc-entry> child elements. 

The <cc-entry> element contains information related to a particular pending communication completion request. The 
<cc-entry> element contains a <orig-URI> element, a <called-URI> element, an optional <term-URI> child element 
and a <expiration> child element. 
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The <orig-URI> element contains the identity of the caller. 

The <called-URI> element contains the identity called by the caller. 

The <term-URI> element contains the identity where the call was routed to. The <term-URI> element is included in the 
<cc-entry> element, if the identity where the call was routed to was provided by the terminating side and unless the 
privacy was requested. 

The <expiration> element indicates the expiration of the communication completion request. 

4.10.2.7 Naming conventions 

When stored in a directory of a user within the "users" subdirectory of the communication completion request records 
XCAP application usage, the filename of the communication completion request records XML document is "index". 

4.10.2.8 Resource interdependencies 

When the communication completion request records XML document is stored in a directory of a user identified by a 
URI within the "users" subdirectory of the communication completion request records XCAP application usage, then 
the <orig-URI> elements contain the URI of the user owning the document. 

4.10.2.9 Authorization policies 

The owner of the communication completion request records XML document is allowed to read the XML document. 
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Annex A (informative): 
Signalling flows 

A.1 CCBS activation and CCBS call 
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UE-A 



Intermediate IM CN 
subsystem entities 



-1. INVITE sip:UE-[ 



HO. 183 Session progress 



O-AS 



-2. INVITE- 
-3. INVITE- 



T-AS 



-4. INVITE- 



7. 486 Busy 
Call-Info: <T-AS>; 
purpose=call-completion; 
m=BS; 



-8. 486 Busy- 



1-9. 183 Session progress- 



IVR: CCBS possible and activation 



-11. SUBSCRIBE 

12. SUBSCRIBE sip:T-AS;m=BS 
P-Asserled-ldentity:<UE-A> 
From:<UE-A> 
-To:<UE-B> 
Contact:<0-AS> 

Call-lnfo:<UE-A>;purpose=call-completion;m=BS 
Eventicall-completion 



-13.202Accepted- 



-14.202 Accepled- 



15. NOTIFY sip:0-AS 
Event:call-completion_ 

[cc-slale:queued 
cc-service-retention] 



UE-B 



—5. INVITE— 
-6. 486 Busy- 



busy State supervision 
begins 



-16. NOTIFY- 
-17.200OK- 



IVR: CCBS activated 



-18.200OK- 
L 



-20. 486 Busy- 



<26. REFER sip:UE-A;m=BS— 
27. 200 OK 



-29. INVITE- 



-19. 486Busy- 



21.NOTIFYsip:0-AS 
-Event:call-completion— 
[cc-state:ready] 



user B becomes 
available 



-22. NOTIFY- 
-23. 200 OK- 



-24. 200 OK- 



■«25. REFER sip:UE-A;m=BS- 



-28. 200 OK- 



-30. INVITE- 
-31.INVITE- 



32. INVITE sip;UE-B;m=BS 
Call-lnfo:<UE-B>;purpose=call-complelion;m=BS; 



-33. INVITE- 



Figure A.1 .1 : CCBS activation and CCBS call 

Figure A. 1.1 shows a basic signalling flow for a CCBS activation and a CCBS call. 
Call flows 
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1 to 5: The communication is initiated by UE-A by sending an INVITE request. The Request-URI will include the 
URI of UE-B. After IPC evaluation in the S-CSCF the INVITE request is routed to the originating AS and after 
that to the terminating AS and further on to UE-B. 

Table A.1-1: SIP INVITE request (UE to P-CSCF) 



INVITE sip:user2_public2@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : sip ipcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 
Accept -Contact : * ; +g. 3gpp . icsi-ref = "urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 
To : <sip : user2_public2@home2 . net> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, REFER 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



6: UE-B answers with a 486 (Busy Here) response. The 486 (Busy Here) response is routed back to the terminating 
AS. 

7 to 8: The terminating AS inserts a Call-Info header field in the 486 (Busy Here) response according to the 
procedures described in RFC 6910 [5]. The Call-Info header field will contain the URI of the terminating AS 
with an "m" header field parameter set to "BS" (busy subscriber). It further includes a "purpose" header field 
parameters set to "call-completion". The 486 (Busy Here) response is routed back to the originating AS. 
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Table A.1-2: 486 (Busy Here) response (Terminating AS to S-CSCF)) 



SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP tas . home2 . net ;branch= z9hG4bK332b23 . 1, SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK344a65 .1, SIP/2 .0/UDP 
icscf2_s .home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP oas .homel .net ;branch=z9hG4bKnashds7, 
SIP/2 . 0/UDP pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, 
[5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To : <sip : user2_public2@home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

CSeq: 127 INVITE 

Retry-After: 3600 

Contact : <sip :user2_public2@visited2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91ewxyz>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Content-Length: 

Call -Info : <sip : tas .home2 . ne t>; purpose =call-complet ion ;m=BS 



9 to 10: The originating AS sends back a 183 (Session Progress) response to UE-A and initiates IVR procedures. 
User A is informed that CCBS is possible. User A activates CCBS. 

1 1 to 12: The originating AS subscribes for the call-completion event package according to the procedures 

described in RFC 6910 [5] at the terminating AS. The originating AS generates a SUBSCRIBE request which 
Request-URl will include the URI of the terminating AS. In order to mark the SUBSCRIBE request as a request 
for CCBS, the originating AS adds the "m" SIP URI parameter with the value "BS" to the Request-URL The 
From header field will include the caller URI. The To header field will include the callee URI. 

Table A.1-3: SUBSCRIBE request (Originating AS to S-CSCF) 



SUBSCRIBE sip:tas.home2 .net;m=BS SIP/2.0 

Via: SIP/2. 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip : scscf 1 .homel .net> 

P-Asserted-Identity : <sip: userl_publicl@homel .net> 

From: <sip : userl_publicl@homel .net>; tag=31415 

To : <sip : user2_public2@home2 . net> 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

Call -Info : <sip :userl_publicl@homel . net >; purpose =call-complet ion ;m=BS 

CSeq: 61 SUBSCRIBE 

Event: call-completion 

Expires: 270 

Contact: <sip : oas .homel .net> 

Content-Length: 



13 to 14 The terminating AS accepts the subscription and starts busy state supervision procedures on the callee. 
Table A.I -4: 202 (Accepted) response (Terminating AS to S-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK344a65 . 1 , SIP/2. 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2 . 0/UDP 

scscf 1. homel .net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 
Record-Route : 
From: 

To : <sip : user2_public2®home2 . net> ; tag=151170 
Call-ID: 
CSeq: 
Event : 

Expires: 270 

Contact: <sip : tas .home2 .net> 
Content-Length : 



15 to 18: The terminating AS sends a notification to the originating AS, according to the procedures described in 
RFC 6910 [5]. The Request-URI of the NOTIFY request will include the URI of the originating AS. The body 
contains parameters informing of the caller"s call-completion state 'queued' and the availability of the call- 
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completion service retention at the terminating AS. After confirmation of the notification the originating AS 
starts announcements procedures informing about the activation of CCBS. 

Table A.1-5: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY sipioas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas . home2 . net ;branch=z9hG4bK348923 . 1 

Max- Forwards : 70 

Route: <sip : scscf 2 .home2 .net> 

P-Asserted- Identity : <sip : tas .home2 .net> 

From: <sip : user2_public2@home2 . net >;tag=15 1170 

To : <sip : userl_publicl@homel . net> ; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 42 NOTIFY 

Subscription-State: active ;expires=2699 

Event: call-completion 

Contact: <sip : tas .home2 .net> 

Content-Type : application/call-completion 

Content-Length: (...) 

cc-state: queued 
cc-service retention 



19 to 20: The originating AS forwards the 486 (Busy Here) response to UE-A. 

21 to 24: The terminating AS sends a NOTIFY request to the originating AS, according to the procedures described 
in RFC 6910 [5]. The body contains a parameter informing of the caller" s call-completion state 'ready' (for 
recall). The originating AS confirms the notification. 

Table A.1-6: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY sip: oas.homel.net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max- Forwards : 70 

Route: <sip : scscf 2 .home2 .net> 

P-Asserted- Identity : <sip : tas .home2 .net> 

From: <sip :user2_public2@home2 .net>; tag=151170 

To : <sip : userl_publicl@homel . net> ; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 47 NOTIFY 

Subscription-State: active ;expires=1800 

Event: call-completion 

Contact: <sip : tas .home2 .net> 

Content-Type : application/call-completion 

Content-Length: (...) 

cc-state: ready 
cc-service retention 



25 to 28: The originating AS initiates the CCBS recall to UE A (by sending a REFER request, the "m" SIP URI 
parameter set to "BS" will be included in the Request-URI of the REFER request. UE-A confirms the REFER 
request. 
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Table A.I -7: REFER request (Originating AS to S-CSCF) 



REFER sip:userl_publicl@homel .net;m=BS SIP/2.0 

Via: SIP/2. 0/UDP oas.homel.net;branch=z9hG4bK23273846 

Max-Forwards: 70 

Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted- Identity : <sip :oas .homel .net> 

From: <sip :oas .homel .net>; tag=161828 

To : <sip : userl_publicl@homel . net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 REFER 

Refer-To : <sip : user2_public2@home2 . net ;method=INVITE> 

Referred-By: <sip : oas .homel .net> 

Contact: <sip : oas .homel .net> 

Content-Length: 



29 to 30: UE-A starts the CCBS call by sending an INVITE request to UE-B. 

31 to 33: In order to mark the INVITE request as a prioritized request for call -completion, the originating AS adds 
the "m" SIP URI parameter with the value 'BS' to the Request-URL 

Table A.I -8: SIP INVITE request (Originating AS to S-CSCF) 



INVITE sip:User2_public2@home2 .net;m=BS SIP/2 . 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp = sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip :orig®scscf 1 .homel .net; lr> 
Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171829 
To : <sip :user2_public2@home2 .net> 
Call -ID: Cb03a0s09a2sdfglkj 490444 

Call -Info : <sip :userl_publicl@homel .net>;purpose=call-completion;m=BS 
Cseq: 154 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bg6>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 
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A.2 CCBS suspend and resume procedures 



UE-A 



Intermediate IM CN 
subsystem entities 



0-AS 



T-AS 



CCBS Recall fails, suspension 



1. PUBLISH sip:T-AS;m=BS 
P-Asserted-ldentity:<UE-A> 
From:<UE-A> 
^To:<UE-B> 
Contact:<0-AS> 
[status_basic= closed] 



-2. PUBLISH- 



-3. 200 OK- 



-4. 200 OK- 



5. NOTIFY sip:0-AS 
-Event: call-completion- 
[cc-state:queued] 



UE-B 



queue entry is 
suspended 



-6. NOTIFY- 



-7. 200 OK- 



-8. 200 OK- 



supervision, A becomes not busy 



9. PUBLISH sip:T-AS;m=BS 
P-Asserted-ID:<UE-A> 
From:<UE-A> 
^To:<UE-B> 
Contact:<0-AS> 
[status_basic=open] 



-10. PUBLISH- 

I 
-11. 200 OK— 



-12. 200OK- 



13. NOTIFY sip:0-AS 
-Event: call-completion- 
[cc-state:queued] 



queue entry is 
resumed 



-14. NOTIFY- 



-15. 200OK- 



-16. 200OK- 



Figure A.2.1 : CCBS suspend and resume procedures 

Figure A.2.1 shows a basic signalling flow for CCBS suspend and resume procedures. 

Call flows 

1 to 4: UE-A is busy and the CCBS recall fails. The originating AS initiates the suspension procedure. It generates a 
PUBLISH request according to the procedures described in RFC 6910 [5]. The Request-URl of the PUBLISH 
request includes the URl of the terminating AS. The From header field includes the URl of UE-Aand the To 
header field includes the URl of UE-B. The body of the PUBLISH request indicates the PIDF state 'closed'. 
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Table A.2-1 : PUBLISH request (Originating AS to S-CSCF) 



PUBLISH sip: sip: tas.home2 .netohomel .net ;m=BS SIP/2.0 

Via: SIP/2. 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip: scscfl .homel .net> 

P-Asserted- Identity : <sip:userl_publicl@homel .net> 

From: <sip :userl_publicl(ahomel .net>; tag=31415 

To: <sip:user2_public2(ahome2 .net>; tag=151170 

Call -ID: b8 9rjhnedlrf jflslj40a222 

CSeq: 71 PUBLISH 

Event: presence 

Expires: 1800 

Content-Type : application/pidf +xml 

Content -Length: (...) 



<?xml vers ion=" 1.0 
<presence xmlns 



encoding= "UTF- 8 " ? > 
urn : ietf : params : xml : ns : pidf " 
xmlns : rpid="urn: ietf : params :xml :ns :pidf : rpid" 
xmlns :dm="urn: ietf : params :xml :ns :pidf : data-model" 
xmlns :pcp="urn: ietf : params :xml :ns :pidf : caps" 
xmlns : c="urn: ietf : params :xml :ns :pidf : cipid" 
entity="pres :user2_publicl(ahome2 .net "> 

< tuple id="a8098a.672364762364"> 

<status> 

<basic>closed</basic> 

</status> 
</tuple> 

</presence> 



5 to 8: The terminating AS suspends the queue entry and sends a NOTIFY request to the originating AS, according 
to the procedures described in RFC 6910 [5]. The body contains a parameter informing of the caller's call- 
completion state 'queued'. The originating AS starts busy state supervision procedures on UE-A. 



Table A.2-2: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY sip: oas. homel. net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max-Forwards: 70 

Route: <sip : scscf 2 .home2 .net> 

P-Asserted- Identity : <sip : tas .home2 .net> 

From: <sip :user2_public2@home2 . net >;tag=15 1170 

To : <sip : userl_publicl@homel . net> ; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 72 NOTIFY 

Subscription-State: active ;expires=1795 

Event: call-completion 

Contact: <sip : tas .home2 .net> 

Content-Type : application/call-completion 

Content-Length: (...) 

cc-state: queued 
cc-service retention 



9 to 12: UE-A becomes not busy. The originating AS initiates the resumption procedure. It generates a PUBLISH 
request according to the procedures described in RFC 6910 [5]. The Request-URI of the PUBLISH request 
includes the URl of the terminating AS. The From header field includes the URl of UE-A and the To header 
field includes the URl of UE-B. The body of the PUBLISH request indicates the PIDF state 'open'. 
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Table A.2-3: PUBLISH request (Originating AS to S-CSCF) 



PUBLISH sip: sip: tas.home2 .netohomel .net ;m=BS SIP/2.0 

Via: SIP/2. 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip: scscfl .homel .net> 

P-Asserted-Identity : <sip: userl_publicl(ahomel .net> 

From: < sip: user l_publicl@homel .net>; tag=31416 

To: <sip:user2_public2(ahome2 .net>; tag=151170 

Call -ID: b89rjhnedlrf jflslj40a222 

CSeq: 85 PUBLISH 

Event : presence 

Expires: 1100 

Content-Type : application/pidf +xml 

Content -Length: (...) 



<?xml vers ion=" 1.0 
<presence xmlns 



encoding= "UTF- 8 " ? > 
urn : ietf : params : xml : ns : pidf " 
xmlns : rpid="urn: ietf : params :xml :ns :pidf : rpid" 
xmlns :dm="urn: ietf : params :xml :ns :pidf : data-model" 
xmlns :pcp="urn: ietf : params :xml :ns :pidf : caps" 
xmlns : c="urn: ietf : params :xml :ns :pidf : cipid" 
entity="pres :user2_publicl(ahome2 .net "> 

< tuple id="a8098a.672364762364"> 

<status> 

<basic>open</basic> 

</status> 
</tuple> 

</presence> 



13 to 16: The terminating AS resumes the queue entry and sends a NOTIFY request to the originating AS, 

according to the procedures described in RFC 6910 [5]. The body contains a parameter informing of the caller"s 
call-completion state 'queued'. 

Table A.2-4: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY sip: oas. homel. net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max-Forwards: 70 

Route: <sip : scscf 2 .home2 .net> 

P-Asserted- Identity : <sip : tas .home2 .net> 

From: <sip :user2_public2@home2 . net >;tag=15 1170 

To : <sip : userl_publicl@homel . net> ; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 86 NOTIFY 

Subscription-State: active ;expires=1095 

Event: call-completion 

Contact: <sip : tas .home2 .net> 

Content-Type : application/call-completion 

Content-Length: (...) 

cc-state: queued 
cc-service retention 
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A.3 CCNR activation 



UE-A 



Intermediate IM CN 
subsystem entities 



-1. INVITE sip:UE-E 



-10. 180Ringing- 



0-AS 



-2.INVITE- 
-3. INVITE- 



T-AS 



7. 180 Ringing 
Call-Info: <T-AS>; 
purpose=call-completion; 
m=NR; 



8. 180 Ringing 
Call-Info: <T-AS>; 
purpose=call-completion; 
m=NR; 



. IBGRInging- 



IVR: CCNR possible and activation 



-11. SUBSCRIBE 

12. SUBSCRIBE sip:T-AS;m=NR 
P-Asserted-ldentity:<UE-A> 
From;<UE-A> 
-To:<UE-B> 
Contact:<0-AS> 

Call-Info: <UE-A>;purpose=call-completion;m=NR 
Event: call-completion 



-13. 202Accepted- 



-14. 202Accepted 



15. NOTIFY sip:0-AS 
_Event:call-completion_ 
[cc-state:queued 
cc-service-retention] 



UE-B 



5. INVITE 

-6. ISORinging- 



-16. NOTIFY- 
-17.200OK- 



IVR: CCNR activated 



-18.200OK- 

I 



-19. CANCEL- 



-28. 200 OK (CANCEL)- 



-33. 487 (INVITE)- 
34. ACK 



-20. CANCEL- 
-21.CANCEL- 



-22. CANCEL- 



-26. 200 OK (CANCEL)- 



-26. 200 OK (CANCEL) — ► 
-27. 200 OK (CANCEL)— 



-30. 487 (INVITE)- 



-31.487(INVITE)- 
-32. 487 (INVITE)- 



-35. ACK- 
-36. ACK- 



-37.ACK- 



user B activity 
supervision begins 



23. CANCEL 

-24. 200OK(CANCEL)- 



-29. 487 (INVITE)- 



-38. ACK- 



Figure A.3.1 : CCNR activation 

Figure A.3.1 shows a basic signalling flow for a CCNR activation. 
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Call flows 



1 to 5: The communication is initiated by UE-A by sending an INVITE request. The Request-URI will include the 
URI of UE-B. After IPC evaluation in the S-CSCF the INVITE request is routed to the originating AS and after 
that to the terminating AS and further on to UE-B. 



Table A.3-1 : SIP INVITE request (UE to P-CSCF) 



INVITE sip:user2_public2@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route: sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip : origOscscf 1 .homel .net ; lr> 
Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 
To : <sip : user2_public2@home2 . net> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree; replaces 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf6>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 



6: UE-B answers with a 180 (Ringing) response. The 180 (Ringing) response is routed back to the terminating AS. 

7 to 8: The terminating AS inserts a Call-Info header field in the 180 (Ringing) response according to the procedures 
described in RFC 6910 [5]. The Call-Info header field will contain the URI of the terminating AS with a "m" 
header field parameter set to "NR" (no reply). It further includes a "purpose" header field parameter set to "call- 
completion". The 180 (Ringing) response is routed back to the originating AS. 



£75/ 



3GPP TS 24.642 version 9.1 0.0 Release 9 41 ETSI TS 1 24 642 V9.1 0.0 (201 3-07) 

Table A.3-2: 180 Ringing (Terminating AS to S-CSCF)) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP tas .home2 .net ;branch= z9hG4bK332b23 . 1, SIP/2. 0/UDP 
scscf2.home2 .net ;branch=z9hG4bK344a65 .1, SIP/2 .0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2 . 0/UDP 

scscf 1. homel.net ;branch=z9hG4bKehuehjgt, SIP/2 . 0/UDP oas .homel .net ;branch=z9hG4bKnashds7, 
SIP/2 . 0/UDP pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, 
[5 555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To : <sip : user2_public2@home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

CSeq: 127 INVITE 

Retry-After: 3600 

Contact : <sip :user2_public2@visited2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91ewxyz>;+g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Content-Length: 

Call -Info : <sip : tas .home2 .net>;purpose=call-completion;m=NR 



9 to 10: The originating AS removes the Call-Info header field, forwards the 180 (Ringing) response to UE-A and 
initiates IVR procedures. User A is informed that CCNR is possible. User A activates CCNR. 

1 1 to 12: The originating AS subscribes for the call-completion event package according to the procedures 

described in RFC 6910 [5] at the terminating AS. The originating AS generates a SUBSCRIBE request which 
Request-URl will include the URl of the terminating AS. In order to mark the SUBSCRIBE request as a request 
for CCNR, the originating AS adds the "m" SIP URl parameter with the value "NR" to the Request-URl. The 
From header field will include the caller URl. The To header field will include the URl of UE-B. 

Table A.3-3: SUBSCRIBE request (Originating AS to S-CSCF) 



SUBSCRIBE sip:tas.home2.net;m=NR SIP/2.0 

Via: SIP/2. 0/UDP oas. homel. net ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip : scscf 1 .homel .net> 

P-Asserted- Identity : <sip :userl_publicl@homel .net> 

From: <sip :userl_publicl@homel .net>; tag=31415 

To : <sip :user2_public2@home2 .net> 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 61 SUBSCRIBE 

Call-Inf o : <sip :userl_publicl@homel .net>;purpose=call-completion;m=NR 

Event: call-completion 

Expires: 54 

Contact: <sip : oas .homel .net> 

Content-Length: 



13 to 14 The terminating AS accepts the subscription and starts supervision procedures on activity of the callee. 
Table A.3-4: 202 (Accepted) response (Terminating AS to S-CSCF) 



SIP/2.0 202 Accepted 

via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK344a65 . 1 , SIP/2. 0/UDP 

icscf2_s .home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 
Record-Route : 
From: 

To : <sip : user2_public2@home2 . net> ; tag=151170 
Call-ID: 
CSeq: 
Event : 

Expires: 5400 

Contact: <sip : tas . home2 . net> 
Content-Length : 



15 to 18: The terminating AS sends a notification to the originating AS, according to the procedures described in 
RFC 6910 [5]. The Request-URl of the NOTIFY request will include the URl of the originating AS. The body 
contains parameters informing of the caller"s call-completion state 'queued' and the availability of the call- 
completion service retention at the terminating AS. After confirmation of the notification the originating AS 
starts announcements procedures informing about the activation of CCNR. 
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Table A.3-5: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY sipioas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max-Forwards: 70 

Route: <sip : scscf 2 .home2 .net> 

P-Asserted- Identity : <sip : tas .home2 .net> 

From: <sip :user2_public2@home2 . net >;tag=15 1170 

To : <sip : userl_publicl@homel . net> ; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 42 NOTIFY 

Subscription-State: active ;expires=5399 

Event: call-completion 

Contact: <sip : tas .home2 .net> 

Content-Type : application/call-completion 

Content-Length: (...) 

cc-state: queued 
cc-service retention 



19 to 28: UE-A initiates the termination of the session setup by sending a CANCEL request to UE-B. 
29 to 38: UE-B terminates the session setup by sending a 487 Request terminated to UE-A. 



A.4 CCNRcall 



UE-A 



Intermediate IM CN 
subsystem entities 



-6. REFER 3ip:UE-A;m=BS 
7. 200 OK 



-9. INVITE- 



0-AS 



T-AS 



1. NOTIFY sip:0-AS 
-Eventcall-completion- 
[cc-state:ready] 



UE-B 



UE-B becomes available 



-2. NOTIFY- 
-3. 200 OK- 



-4. 200 OK- 



-5. REFER sip:UE-A;m=BS 



-8. 200 OK- 



10. INVITE 

-11. INVITE sip:UE-B;m=NR- 
12. INVITE sip:UE-B;m=NR- 



-13. INVITE sip:UE-l 



Figure A.4.1: CCNRcall 

Figure A.4.1 shows a basic signalling flow for a CCNR operation and a CCNR call. 
Call flows 



1 to 4: The terminating AS sends a NOTIFY request to the originating AS, according to the procedures described 
in RFC 6910 [5]. The body contains a parameter informing of the caller"s call-completion state "ready" (for 
recall). The originating AS confirms the notification. 
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Table A.4-1 : NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY sipioas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max-Forwards: 70 

Route: <sip : scscf 2 .home2 .net> 

P-Asserted- Identity : <sip : tas .home2 .net> 

From: <sip :user2_public2@home2 . net >;tag=15 1170 

To : <sip : userl_publicl®homel . net> ; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 47 NOTIFY 

Subscription-State: active ;expires=18 

Event: call-completion 

Contact: <sip : tas .home2 .net> 

Content-Type : application/call-completion 

Content-Length: (...) 

cc-state: ready 
cc-service retention 



5 to 8: The originating AS initiates the CCNR recall to UE A by sending a REFER request, the "m" SIP URI 
parameter set to "NR" will be included in the Request-URI of the REFER request. UE-A confirms the REFER 
request. 

Table A.4-2: REFER request (Originating AS to S-CSCF) 



REFER sip:userl_publicl@homel.net;m=NR SIP/2.0 

Via: SIP/2. 0/UDP oas .homel .net ;branch=z9hG4bK23273846 

Max-Forwards: 70 

Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted- Identity : < sip: oas .homel .net> 

From: <sip : oas .homel .net>; tag=161828 

To : <sip : userl_publicl@homel . net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 REFER 

Refer-To : <sip : user2_public2@home2 . net ;method=INVITE> 

Referred-By: <sip : oas .homel .net> 

Contact: <sip : oas . homel . net> 

Content-Length: 



9 to 10: UE-A starts the CCNR call by sending an INVITE request to UE-B. 

11 to 13: In order to mark the INVITE request as a prioritized request for call-completion, the originating AS 

adds the "m" SIP URI parameter with the value "NR" to the Request-URI, and forwards the INVITE request to 



UE-B. 



Table A.4-3: SIP INVITE request (Originating AS to S-CSCF) 



INVITE sip:User2_public2@home2 .net;m=NR SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : sip :pcscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171829 
To : <sip : user2_public2®home2 . net> 
Call -ID: Cb03a0s09a2sdfglkj 490444 
Cseq: 154 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bg6>; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept : application/sdp, application/3gpp-ims+xml 

Call -Info : <sip :userl_publicl@homel .net>;purpose=call-completion;m=BS 
Content-Type: application/sdp 
Content-Length: (...) 
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Annex B (informative): 
Example of filter criteria 

B.O General 

This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 



B.1 Originating 



An example of an IFC when the CCBS or CCNR services are active at the originating S-CSCF is: 
- Method: INVITE. 



B.2 Terminating side 



Examples of the IFC at the terminating S-CSCF when the user is registered and CCBS or CCNR or both are supported 
are: 

- Method: INVITE. 

- Method: SUBSCRIBE. 
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Annex C (informative): 
lANA Registration templates 

C.1 lANA registry for application media types 

C.1 .1 I ANA registration template for 
application/vnd.3gpp.ccrr+xml 

Editor's note: The MIME type "application/vnd.3gpp.ccrr+xml" as defined in this subclause is to be registered in the 
lANA registry for AppHcation Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd . 3 gpp . ccrr+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [11]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [11] 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [11]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [13] apply. Furthermore, 3GPP has defined mechanisms for ensuring the privacy and integrity 
protection of the bodies of XCAP messages used in the 3GPP IM CN Subsystem. 

Interoperability considerations: 

Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [11]. 

Published specification: 

3GPP TS 24.642 "Completion of Communications to Busy Subscriber (CCBS), Completion of Communications by No 
Reply (CCNR) using IP Multimedia (IM) Core Network (CN) subsystem", version 9.1.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Apphcations that use the 3GPP IM CN Subsystem as defined by 3GPP. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 
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2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 
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